Connection Pool
DBへのセッションを使い回す仕組みのこと
モチベーション
リクエストごとにconnectionを作るのは効率が悪いので、予め一定数のconnectionを作っておき、必要なときにそれを使い回す 基本的な動き
2. アプリが DB クエリを実行したい時にプールからコネクションを借りる
3. 使い終わったらコネクションを返す
生存監視
再接続
Idle 時のクローズ
etc.
gpt-5.icon
よく出る設定項目
プールが保持できる最大コネクション数。
多すぎる → DB が死ぬ
少なすぎる → アプリの待ち時間が増える
→ アプリの並列度 & DB の性能に応じて調整
min pool size（最小接続数）
キープしておく接続数。
ワークロードの急増時に「接続作成のスパイク」が起きないようにする。
idle timeout / max lifetime
idle timeout：使っていない接続を閉じるまでの時間
max lifetime：どれだけ生き続けても OK か（DB 側の制限に合わせる）
特に RDS / Aurora は長生きしすぎたコネクションが突然切られることがあるため、max lifetime は重要。
connection timeout
プールからコネクションを借りる際、
「これ以上待ったらエラーにする」
という設定。
client側で制御する
カーネルにせよ、データベース層にせよ、結局はメモリなどのハードウェアリソースをいたずらに消費しないための制限である。 メモリが溢れてディスクへのスワップが発生し、データベースサーバが停止すると、システム全体に影響する。 システム全体に影響を与えるくらいなら、クライアント側で上限を設けておいて、多少の接続待ちが起きてもよいことにする。
ここでの「client」はWeb Appサーバーのこと
わかりやすい